REMARKS 

Reconsideration and allowance of the above-referenced application are respectfully 
requested. Claim 13 is amended, and claims 1-39 are pending in the application. 

It is believed that claim 13 as amended overcomes the rejection under 35 USC §112, 
second paragraph. Hence, this rejection should be withdrawn. 

Claims 1, 12, 19 and 30 stand rejected under 35 USC § 102(e) in view of U.S. Patent No. 
6,314,531 to Kram. These rejections are respectfully traversed. 

Each of the independent claims 1, 12, 19 and 30 specify emulation in a protocol emulator, 
where IP frames are promiscuously detected on a network interface. An executable emulation 
application within the protocol emulator generates, for each corresponding detected IP frame, a 
response IP frame. Each response IP frame is output by a raw socket onto the network interface. 

As described in the specification (e.g., page 2, lines 17-23, page 3, lines 1-3), the 
promiscuous detection of IP frames on the network interface eliminates the necessity for 
conventional IP filtering of received IP frames that normally is performed by a UNIX kernel. 
Moreover, the generation of a response IP frame for each corresponding detected IP frame by 
the executable emulation application results in the executable emulation application being able to 
emulate an unlimited number of IP devices, since a UNIX descriptor is no longer needed for each 
and every IP address emulated by the protocol emulator; rather, the executable emulation 
application generates a response EP frame for each detected IP frame, regardless of IP address. 
Finally, each response IP frame is output by the raw socket onto the network interface, enabling 
kernel resources to be bypassed, further reducing the reliance on operating system resources such 
as the UNIX kernel. 

These and other features are neither disclosed nor suggested in the applied prior art. 

Kram does not disclose or suggest: (1) generating, for each corresponding 
(promiscuously) detected IP frame, a response IP frame by an executable emulation application, 
or (2) outputting each said response IP frame by a raw socket onto the network interface. 

In fact, Kram specifically avoids generating a response DP frame for each promiscuously 
detected IP frame by (1) filtering the promiscuously detected packets based on MAC addresses 
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or IP addresses, and (2) selectively dropping packets based on whether the emulation model 

specifies that a link is "down", or due to a "transient outage". 

Figure 4 of Kram illustrates the data flow between functional components of the 

emulator. Although a promiscuous reader 403 examines all packets seen by the directly 

connected network interfaces, the reader 403 is coupled to filter 405 that filters out packets: 

This reader [403] is coupled to a filter 405 which filters out all packets not containing one 
of the MAC addresses of the emulator host . It also filters out all packets containing the IP 
address of the emulator host because these packets are destined to other processes on 
the emulator host . The filter passes on to the simulation component 407 all packets 
containing the MAC address of the emulator host and an IP address of one of the test 
computers . 

(Column 6, lines 34-43). 

Hence, Kram teaches that not all the packets that are promiscuously detected are 
forwarded to the simulation component 407; rather, Kram explicitly specifies that packets are not 
sent to the simulation component unless the packet specifies (1) one of the MAC addresses of 
the emulator host, and (2) an IP address of one of the test computers. Rather, Kram requires that 
packets are excluded from the simulation component 407 if they specify (1) a MAC address that 
is not assigned to the emulator host, or (2) the IP address of the emulator host . 

Hence, any packet containing the IP address of the emulator host is filtered because it 
"destined to other processes on the emulator host". Hence, it is impossible for Kram to teach 
"generating a response IP frame for each detected IP frame", as claimed. 

For this reason alone the §102 rejection should be withdrawn because it fails to 
demonstrate that the applied reference discloses each and every element of the claim . See MPEP 
2131. "The identical invention must be shown in as complete detail as is contained in the ... 
claim." Richardson v. Suzuki Motor Co. . 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 
1 989). "Anticipation cannot be predicated on teachings in the reference which are vague or 
based on conjecture." Studiengesellschaft Kohle mbH v. Dart Industries, Inc. , 549 F. Supp. 716, 
216 USPQ 381 (D. Del. 1982), affcL, 726 F.2d 724, 220 USPQ 841 (Fed. Cir. 1984). 
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Further, Kram cannot disclose the claimed generating a response IP frame for each 
corresponding detected IP frame because Kram describes that the simulation component drops 
the packet if the emulation model determines the link the packet is traversing (determined based 
on the source and destination IP addresses) is down (col. 6, lines 49-58); further, "if the link is 
up, the simulation component [407] computes whether the packet should be dropped (because of 
a transient outage) and if so the packet is discarded " (col. 6, lines 58-60). 

Hence, Kram cannot teach the claimed generation of a response IP frame for each 
corresponding detected IP frame because Kram specifically requires that the emulator 
" deliberately corrupt or fail to deliver (drop) any specific packet or sequence of packets and 
thus introduce data corruption and network outages of various durations. .." (col. 5, lines 59-61). 

For this reason alone the §102 rejection should be withdrawn. 

Further, Kram does not generate any response IP frame, at all. Rather, Kram describes 
that the network emulator simulates wide area network traffic conditions (e.g., latency, 
congestion, failed links, etc.) by delaying and dropping packets . As described above, Kram 
requires the periodic dropping of packets: the dropping of packets cannot be in any way be 
reasonably considered a response IP frame , especially since the packet is dropped . 

Delaying or corrupting a packet as described at column 6, line 61 to col. 7, line 29 cannot 
be considered generating a response IP frame, because the only disclosed change that might 
occur to the original detected IP frame is corruption of the data frame. Kram replaces the 
destination MAC address for the original IP frame and outputs the original IP frame with the 
updated MAC address, and does not generate a response IP frame. "All words in a claim must 
be considered in judging the patentability of that claim against the prior art." In re Wilson, 424 
F.2d 1382, 1385, 165 USPQ494, 496 (CCPA 1970)." 

Further, any assertion that a corrupted frame could be considered a legitimate "response 
IP frame" that is generated for the corresponding detected IP frame is without foundation, and 
unreasonable because it is inconsistent with the specification or how one skilled in the art would 
interpret "response IP frame". See MPEP § 21 1 1.01 at 2100-37 (Rev. 1, Feb. 2000) ("claims are 
not to be read in a vacuum, and limitations therein are to be interpreted in light of the 
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specification in giving them their 'broadest reasonable interpretation.'" (quoting In re Marosi , 
218 USPQ 289, 292 (Fed. Cir. 1983)(emphasis in original))). Cf. In re Cortrieht . 49 USPQ2d 
1464, 1468 (Fed. Cir. 1999). Regardless, Kram teaches that not all detected IP frames are 
delayed, corrupted, or dropped, hence Kram cannot disclose the claimed generating a response IP 
frame for each corresponding detected IP frame. 

For this reason alone the §102 rejection should be withdrawn. 

Finally, Kram does not teach the claimed "outputting said each response IP frame", let 
alone outputting by a raw socket onto the network interface, let alone "for transmission on the 
network" (see claim 12). In fact, the assertion that Kram discloses a raw socket is misplaced, 
especially since Kram provides no reference whatsoever to any socket, let alone a raw socket , as 
claimed. 

For these and other reasons, the §102 rejection should be withdrawn. 

The indication of allowable subject matter in claims 2-11, 13-18, 20-29, and 31-39 is 
acknowledged with appreciation. It is believed these claims are allowable in view of the 
foregoing. 

In view of the above, it is believed this application is in condition for allowance, and such 
as Notice is respectfully solicited. 

To the extent necessary, Applicant petitions for an extension of time under 37 C.F.R. 
1 .136. Please charge any shortage in fees due in connection with the filing of this paper, 
including any missing or insufficient fees under 37 C.F.R. 1.17(a), to Deposit Account, No. 
50-1 130, under Order No. 95-451, and please credit any excess fees to such deposit account. 




Leon R. Turkevich 
Registration No. 34,035 



Customer No. 23164 
Date: December 7, 2005 
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